1. Field of the Invention
The present invention relates to a system for monitoring a label switched path (LSP) set up in a network in which packet forwarding is done by MPLS (Multiprotocol Label Switching) method.
2. Background
MPLS is a technology for speeding up packet forwarding in the Internet. In the technology, a router does not determine a forwarding destination of a packet by looking up the address in the network layer of the packet, but does fast switching with a label put on a packet. In a network adopting this technology, an LSP is set up by an exchange of a message of the RSVP (Resource ReSerVation Protocol), the LDP (Label Distribution Protocol), or the like between an ingress router and an egress router or between neighboring routers on a path from an ingress point to an egress point.
For a manager of an internet service provider (ISP) which operates a network that adopts this MPLS method, a tool that visualizes what LSP is set up in the network would be useful. For example, a US company WANDL provides a visualization tool called “IP/MPLSView”. This visualization tool of WANDL infers and displays an LSP to be set up, by collecting configuration information from each router in a network and simulating the behavior of various protocols between routers based on the collected configuration information. For this reason, the visualization tool of WANDL cannot visualize an LSP that is actually set up.
On the other hand, an art is proposed in which, when there is a trouble in an LSP, it is determined where in the LSP the trouble occurred (Japanese Patent Laid-Open Application No. 2002-111666). In this art, traffic at an ingress router of the LSP is measured and, when a trouble is detected, an LSP is found out to check where in the path the trouble occurred. Specifically, a path of an LSP is determined based on router information included in an LDP message that was exchanged to set up the LSP, in which a loop detection mode was used. Thereafter, traffic that flows between routers on the determined path is observed to identify the cause of the trouble.
Even in the above art, however, an LSP is found out only when traffic is sent through the LSP, and thus an LSP that is actually setup cannot be found. This is because there is sometime passage after an LSP was set up by a message exchange till traffic is actually sent through the LSP and because a path cannot be searched for unless traffic flows in the above art since its purpose is to monitor troubles.
For example, in a case where a manager of an ISP, in order to do construction on an LSP, uses another alternative LSP, the manager would want to carry out the steps of conducting various checks about a setup of the alternative LSP and then switching traffic which has been sent through the original LSP to the alternative LSP. In the above art, however, since no traffic flows through the alternative LSP before switching, the alternative LSP cannot be searched for. That is, in the conventional art, a user (a manager of an ISP in the above example) cannot check what path an alternative LSP actually passes through, or a current state (whether the path is connected (UP) or disconnected (DOWN)), or the like before the LSP to send traffic is switched.
Additionally, in the above art, when a trouble occurs in which an LSP is disconnected, the trouble is detected by measuring traffic that flows through the LSP. So, when an LSP with no traffic flow becomes disconnected, this cannot be found until traffic flows. However, it is desirable that a manager of an ISP can immediately find that an LSP becomes disconnected and take measures before traffic flows.